This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims in this application and is not admitted to be prior art by inclusion in this section.
In recent years, mobile broadcast solutions have been standardized by different organizations, such as the 3rd Generation Partnership Project (3GPP) Multimedia Broadcast Multicast Service (MBMS), the Digital Video Broadcasting (DVB) Convergence of Broadcast and Mobile Services (CBMS), and the Open Mobile Alliance (OMA) Broadcast (BCAST) organizations. The two primary services provided by such multicast/broadcast solutions are streaming and file delivery services. Although streaming services are considered to be the primary driver of this technology, file delivery is expected to generate a significant amount of the traffic and activity over time. For example, in the delivery of music and video clips, the file delivery may comprise the primary application component. Alternatively, file delivery may be a secondary component of the application, such as in the case of rich media applications and zapping streams.
In the case of file delivery, File Delivery Over Unidirectional Transport (FLUTE) can be used as the file delivery protocol. As discussed in the Network Working Group's Request for Comments (RFC) 3926, which can be found at www.ietf.org/rfc/rfc3926.txt and is incorporated herein by reference in its entirety, FLUTE is defined by the Internet Engineering Task Force (IETF), and a revision of this document is currently in progress. FLUTE is based on Asynchonous Layered Coding (ALC) Protocol Instantiation, which can be found in RFC 3450 (www.ietf.org/rfc/rfc3451.txt, www.ietf.org/rfc/rfc3451.txt, incorporated herein by reference in its entirety.) ALC comprises a set of building blocks such as the Layered Coding Transport (LCT) block, which can be found in RFC 3451 (www.ietf.org/rfc/rfc3451.txt, www.ietf.org/rfc/rfc3451.txt, incorporated herein by reference in its entirety) and the Forward Error Correction (FEC) building block, which can be found in RFC 3452 (www.ietf.org/rfc/rfc3452.txt, incorporated herein by reference in its entirety). FLUTE extends ALC by, among others, defining mechanisms to describe the contents of the FLUTE session. This is achieved by introducing a well-known object with a Transport Object Identifier (TOI) equal to 0, carrying a File Delivery Table (FDT) instance. The FDT instance lists a set of files and their corresponding transport options. The FDT is an extensible markup language (XML) file following a schema defined in the FLUTE specification. The semantics of the FDT were mainly taken from the Hypertext Transfer Protocol (HTTP) 1.1 protocol, which can be found in RFC 2616 (www.ietf.org/rfc/rfc2616.txt, incorporated herein by reference in its entirety.)
3GPP is currently specifying a rich media solution which will allow for rich media scenes to be multicast to a large set of users and allow for user interactivity. The rich media solution is based on both streaming and file delivery mechanisms. In this solution, the server may transmit rich media scenes, images, and other files over FLUTE, while transport scene updates and other real-time and dynamic content are transmitted over the Real-Time Transport Protocol (RTP). The static content transported over FLUTE may have a longer lifespan than the dynamic content and may be reused a long time after its delivery and by different applications.
With the emergence of new applications such as rich media applications, new requirements for the transport protocols have emerged. Those requirements stem in large part from the need to transport some parts of the content of the application over FLUTE, while the other part is being streamed using RTP. An example of such a scenario is the transport of some images over FLUTE, which are being referred to from a rich media scene. The scene description may be transported over FLUTE or RTP, whereas the scene updates are typically transported over RTP. The receiver does not know a priori when a given image will be deployed in the rich media scene. On the other hand, as only the delivery over FLUTE of such image files is currently possible, a priori download of such files is beneficial, so that they are available at their deployment time in the dynamic rich media scene. Furthermore, some files may be reused quite often by the application, or files may be shared by several applications. In the case of rich media scenes, some image files may represent objects in the rich media scene which may appear and disappear several times within the scene. However, there is currently no signaling in FLUTE or other proposed rich media standards (including the Mobile Open Rich-media Environment (MORE) standard) that can be used by a server to indicate to receivers that a file will be reused by the application.
Although HTTP defines a set of cache control mechanisms to define the behavior of the client, server, and the web cache nodes in the network, it does not define directives for the receiver to store a given object/file for a given period of time. In this arrangement, the server can only indicate an estimation of the expiration time of the object, until which the receiver can assume that the object is up to date.
In light of the above, it would be desirable for a server to be capable of signaling caching recommendations, as foreseen by the sender/content provider, to the receivers. It would also be desirable to be able to have each file contain caching directives for indicating how long a file is to be kept in the cache. It would also be helpful for each file to be assigned a priority, which can be used by the receiver to decide which files to keep in the cache when running out of storage capacity. Lastly, it would be desirable for these types of caching directives to be in the form of recommendations and not mandatory for the receiver. However, FLUTE does not provide caching directives.